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REMARKS/ARGUMENTS 

Prior to this Amendment, claims 1-16, 18, and 19 were pending in the 
application. 

To hasten allowance, claims 1-7 are cancelled with this Amendment. No new 
issues are raised by the claim amendments, which place the application in better 
condition for appeal or for allowance. 

Claims 8-16, 18, and 19 remain in the application for consideration by the 
Examiner. 

Claim Rejections Under 35 U.S,C, 5101 

In the October 3, 2005 Office Action, claims 1-7 were rejected under 35 
U.S.C. §101 as being directed to non-statutory subject matter. Claims 1-7 are 
cancelled. 

Claim Rejections Under 35 U.S.C. S103 

Claims 1-7 were rejected under 35 U.S.C. §103 based on several references. 
Claims 1-7 are cancelled by this Amendment. 

Additionally, in the Office Action of October 3, 2005, clafms 8 and 1 8 were 
rejected under 35 U.S.C. §1 03(a) as being unpatentable over U.S. Patent No. 
5,014,220 ("McMann") in view of "Understanding Fault-Tolerant Distributed Systems" 
fCristian"). This rejection is traversed based on the following remarks. 

As discussed in Applicant's Background and with Applicant's prior response, 
the present invention is addressing the problems with prior network modeling 
techniques that were limited to modeling of hardware devices and their failures and 
repair. The present Invention in contrast provides for availability modeling of 
software components or applications in the network and typically, integrating such 
availability modeling of software components with the modeling of hardware devices 
to provide a more accurate availability model for a network device or node and the 
overall network. 

With the last two Office Actions, McMann is presented and used as the base 
or main reference in rejecting all of the claims as being obvious (i.e., all pending 
claims are rejected based on McMann in view of additional references). Applicant 
believes that McMann teaches the more standard modeling technique that Applicant 
discusses in its Background, and hence, McMann is not effective as providing a 
base reference for rejecting the pending claims, 
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More specifically, McMann teaches a hardware-based reliability model 
generator that can build models using user selected hardware components or 
modules. However, McMann provides no teaching of modeling software as a 
component in its reliability models of networks or computer systems. The lack of 
teaching of modeling software as a component in a network or system can be seen 
in a review of McMann with reference to Figure 2, which shows that the input for the 
model builder 202 is provided by knowledge bases 214 and 216. Reading McMann 
from coL 8, line 17 to col. 9, line 43, it can be seen that components described in 
detail are only hardware components and no discussion of software applications and 
their failure modes or recovery is provided by McMann. Further, McMann in Figure 
4A shows "a typical computer system which may be represented in the BBD 214" 
(see, McMann beginning at col. 9 f line 44). As shown in Figures 4A and 4B and 
described in associated portions of the specification, McMann only teaches modeling 
hardware components (I.e., a system 402, a computer 404, I/O devices 407, a CPU 
406, memory 408, ALU 410, and registers 412). There is not even a suggestion that 
it would be useful to also model software in the computer 404 as part of the reliability 
model 210 generated by model builder 202. 

Independent claims 8 and 18 are directed to modeling a network that includes 
modeling software components, with claim 8 being directed to a method and claim 
18 being directed to a computer program with similar limitations. McMann fails to 
teach modeling of software components but, instead, only discusses hardware 
components in its reliability model. The Office Action on page 8 indicates that 
Applicant is correct that McMann does not teach a software availability model as it 
only teaches modeling of hardware, but the Examiner reasserts that in view Cristian 
it would have been obvious to model software as shown by McMann. The Applicant 
strongly disagrees because the modeling of a hardware component and a software 
component are not identical or, in many cases, even similar. Hence, a modeling 
technique that is applicable to an electronic circuit may or may not be transferable to 
modeling of a software component Hence, the hardware modeling taught by 
McMann does not teach how to perform software modeling or even suggest that 
such modeling would be useful and should be done at all. 
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Even if the hardware modeling of McMann was transferable or applicable to 
software modeling, such a transfer or modification is not an obvious choice to one 
skilled in the art, and the Examiner is requested to provide a specific reference 
where the use of modeling technique for hardware was directly applied to software 
modeling to at least show a motivation. Otherwise, Applicant argues that the 
Examiner is using impermissible hindsight to modify the teaching of McMann, with 
the only motivation being that provided by the Applicant Hence, McMann should be 
removed as a primary reference for rejecting claims 8 and 18. 

More particularly, even if McMann is applied with the additional teaching of 
Cristian, the references fail to teach or suggest the specific steps called for in claim 
8. For example, the combination of these references fails to teach determining 
failure rates and recovery rates for a software component At the top of page 20, the 
Office Action states that McMann teaches failure and recovery rates at col. 6, lines 
5-8. However, this simply discusses the set of all feasible states of the system" 
without a mention of determination of failure "rates" or "recovery rates." Applicant 
respectfully requests that the Examiner explain how generation of state transition 
parameters teaches these elements of claim 8 (i.e., show the Applicant where the 
McMann teaches its transition parameters include failure rates and recovery rates). 
The discussion at the end of page 19 of the Office Action fails to indicate where 
McMann shows the determination of failure and recovery "rates" but instead discuss 
bounds on system reliability and transitions in state that are time dependent. 
Applicant asserts that this does not show the claimed rate determinations of claim 8. 
Since this element is not shown or suggested, McMann fails to support a rejection 
of claim 8. Further, Applicant would like to stress that the use of such rates with 
hardware would not provide the necessary teaching or motivation to apply such 
modeling to software components. 

Additionally, these two references fail to teach generating warm and non- 
warm recoverable error state parameters for a software component and then, as 
called for in claim 8, generating an availability model that includes such state 
parameters for the software component. The Office Action at the middle of page 20 
states that McMann fails to expressly teach the specific errors called for in claim 8, 
such as determining failure rates and recovery rates for warm and non-warm 
recoverable errors for hardware devices (let alone software components). 
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The Office Action asserts, though, that Cristian provides the necessary 
teaching to overcome this deficiency of McMann, However, the citations provided 
again do not teach determination of errors for software components, but instead, 
Cristian at the page 58 citation provided by the Examiner and elsewhere discusses 
failure of a hardware component (i.e., the hardware device labeled a server). The 
difference in the teachings is clear when one considers that a server may run a 
plurality of software applications or components but tracking the failure of the server 
provides little or no insight as to the operation of these running applications as the 
failure may be hardware based or software based. 

If as suggested, by the Examiner, the "server" were considered a group of 
software applications or a software component being used to emulate a hardware 
server, Cristian fails to teach that ft would be desirable to modify the teaching of 
McMann and further fails to teach the specific modeling technique called for in claim 
8. Hence, Cristian taken by itself or in combination with McMann still fails to teach 
each limitation of claim 8. 

Claim 8 calls for determining failure rates for the software component and 
determining recovery rates for that same software component for warm and non- 
warm recoverable errors. Cristian fails to teach such modeling of software 
components as it fails to teach determining failure rates and recovery rates for 
software components (i.e., its "servers") and further, fails to teach obtaining the rates 
for warm and non-warm recoverable errors for a software component. Cristian 
merely discusses fault tolerant systems that may include servers but provides no 
teaching of performing modeling as called for In claim 8 (e.g., where does Cristian 
teach modeling of software implemented servers that includes determining their 
"rates" of recoverable errors and recovery from such errors and then determining 
state parameters based on such determinations). Cristian does not overcome the 
deficiencies noted above for McMann. For these reasons, Applicant requests that 
the rejection of claims 8 and 18 (which includes similar limitations as claim 8) based 
on these two references be withdrawn. 
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Also, in the Office Action, claims 9-15 were rejected under 35 U.S.C. §1 03(a) 
as being unpatentable over McMann in view of Cristian further in view of Malek. 
Claims 9-15 depend from claim 8 and are believed allowable as depending from an 
allowable base claim. Further, Malek fails to overcome the deficiencies of McMann 
and Cristian discussed with reference to claim 8, i.e., Malek does not show modeling 
of software, does not show determination of failure and recovery rates for software 
components in a network, or show determining state parameters based on such 
determined rates. 

In the Office Action, claims 16 and 19 were rejected under 35 U.S.C. §1 03(a) 
as being unpatentable over McMann in view of Malek. This rejection is traversed 
based on the following remarks. 

As discussed with reference to claim 8, McMann fails to teach modeling of 
software components, and thus, with reference to claim 16, McMann necessarily 
also fails to discuss any of the steps that describe processing information regarding 
M a software error within a network model (i.e., McMann fails to show determining a 
recoverable state for a software error, a failure rate for a software error, and a 
recovery rate for a software error as called for in claim 16). Malek does not 
overcome this deficiency of McMann and hence, the combination of McMann and 
MaJek does not teach claim 16. 

Further, the Office Action cites Malek as teaching determining a fraction of 
recovery failures for warm and non-warm recoveries for the software error with its 
mean time to repair (MTTR) calculation. However, a mean time to repair defines, 
generally, the time to repair or overcome a problem. The Malek MTTR does not 
teach a fraction of "failures" from recovery, i.e., a fraction of times that recovery is 
not successful. Hence, nowhere in Malek is a value of "a number of failures to 
recover from said error' 1 discussed, and such a value is not part of the MTTR. The 
Examiner construes "Pdiag" as teaching this concept as this variable is addressing 
the probability the diagnostics will be effective, but Applicants could find no 
indication that such a probability is calculated in the same fashion as the fraction of 
recovery is defined in claim 16. Further, the Pdiag is not incorporated in a 
"recoverable state" for a software error but is instead used to determine the MTTR. 
For this additional reason, claim 16 is believed allowable over Malek. 
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Claim 19 is directed to a computer program product with limitations similar to 
that of claim 16 r and the reasons provided for allowing claim 16 are believed equally 
applicable to claim 19. 

Conclusions 

In view of all of the above, Applicant requests that a timely Notice of 
Allowance be issued in this case. 

No fee Is believed due for this submittal. However, any fee deficiency 
associated with this submittal may be charged to Deposit Account No. 50-1 123. 

Respectfully submitted, 



December 1 . 2005 

Hogan & Hartson llp 

One Tabor Center 

1200 17th Street, Suite 1500 

Denver, Colorado 80202 

(720) 406-5378 Tel 

(720) 406-5301 Fax 
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